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Ada  is  well  known  for  supporting  good  software  engineering  practices  and for  inte  facing  cleanly  with  other  languages; 
these  features  have  only  gotten  better  with  Ada  2005.  The  A#  project  is  an  open-source  implementation  of  Ada 
2005 for  Microsoft’s  .NET  Framework.  Using  A#,  programmers  can  combine  Ada  code  with  reusable  .NET  com¬ 
ponents,  including  modules  written  in  C#,  as  well  as  legacy  component  object  model  components  and  Win32 
Ttynamically  Finked  Eibraries.  This  allows  leveraging  both  the  software  engineering  advantages  of  Ada  and  the 
large  amount  of  reusable  libraries  written  for  .NET.  Additionally,  A#  targets  portable  digital  assistants  and  other 
mobile  and  embedded  devices. 


Similar  to  the  Java  Runtime  Environ¬ 
ment,  Microsoft’s  .NET  Framework  [1, 

2]  is  attractive  to  software  developers  as  it 
provides  a  large  collection  of  precompiled 
classes,  including  security  classes  that 
allow  dynamic  loading  of  modules.  Just  as 
the  Java  2  Micro  Edition  (J2ME)  allows 
Java  programs  to  be  run  on  embedded  and 
mobile  devices,  the  .NET  Compact 
Framework  enables  .NET  applications  to 
be  run  on  these  devices.  Unlike  Java, 
.NET  had  a  goal  of  interfacing  with  lega¬ 
cy  Windows  code.  Therefore,  Microsoft 
provided  mechanisms  in  .NET  for  easily 
combining  legacy  component  object 
model  (COM)  objects  and  Win32  Stdcall 
dynamically  linked  libraries  (DLLs)  with 
new  .NET  code. 

Microsoft  developed  a  flagship  lan¬ 
guage  for  the  .NET  Framework:  C#.  C#  is 
an  object-oriented  language  with  a  syntax 
and  semantics  that  are  very  similar  to  Java. 
While  C#  and  Java  resolve  many  of  the 
really  bad  problems  with  C  and  C++  (in 
particular,  buffer  overflow  vulnerabilities, 

=  versus  ==,  single  character  errors,  etc.), 
they  still  fail  to  meet  many  of  the  almost 
30  year  old  Department  of  Defense 
(DoD)  Steelman  requirements  [3]  for  pro¬ 
gramming  languages  that  have  always  been 
met  in  Ada.  For  example,  while  the  latest 
versions  of  C#  and  Java  have  finally  added 
generics,  both  languages  still  fail  to  provide 
subtypes  to  properly  model  scalar  values, 
and  proper  enumeration  types.  C#  does 
have  an  enum  type,  which  at  first  glance 
appears  to  be  a  proper  enumeration  type, 
but  does  not  provide  successor  or  prede¬ 
cessor  functions.  Additionally,  C#  and  Java 
still  require  arrays  to  be  indexed  with  inte¬ 
gers  starting  at  zero  (Ada  allows  the  start¬ 
ing  index  to  be  specified  or  allows  indexing 
an  array  with  an  enumeration  type,  such  as 
colors). 

Ada,  on  the  other  hand,  has  suffered 
from  a  lack  of  available  components 
(although  Ada  2005  does  add  a  new  con- 
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tainer  library).  Only  a  few  of  the  widely 
used  libraries  support  Ada.  Additionally, 
compiler  vendors  have  been  slow  to  pro¬ 
vide  compilers  for  new  platforms  such  as 
embedded  and  mobile  devices.  As  a  result, 
despite  its  engineering  superiority,  Ada  is 
often  not  the  best  tool  to  get  the  job  done. 

The  A#  projecF  seeks  to  have  the  best 
of  both  worlds.  By  providing  an  open- 
source  compilation  environment  for  Ada 
on  the  .NET  Framework,  A#  gives  soft¬ 
ware  developers  the  opportunity  to  lever¬ 
age  the  large  amount  of  reusable  .NET 
classes  while  also  being  able  to  write  code 
in  a  language  that  strongly  supports  good 
software  engineering  practices. 

Compiling  for  .NET 

One  of  the  key  design  goals  for  .NET  was 
supporting  multiple  different  program¬ 
ming  languages.  Microsoft  provides  tech¬ 
nical  support  to  language  developers  and 
has  published  a  list  of  27  languages  that 
compile  to  .NET  (not  including  the  four 
distributed  with  Visual  Studio)  [4].  To 
make  it  easier  for  compiler  developers  to 
create  compilers  for  the  .NET 
Framework,  Microsoft  provides  the  .NET 
Common  Intermediate  Language  (CIL). 
The  .NET  CIL  can  be  viewed  as  a  high- 
level  assembly  language,  which  directly 
supports  object-oriented  features  such  as 
inheritance,  dispatching,  and  interfaces. 
Since  this  intermediate  language  is  object- 
oriented,  compiling  an  object-oriented 
language  to  the  .NET  CIL  is  much  simpler 
than  compiling  to  Intel  assembly  language. 

The  .NET  CIL  bears  a  strong  resem¬ 
blance  to  Java  bytecode.  Therefore, 
JGNAT  [5]  (Gnu  Ada  Translator  [GNAT] 
for  the  Java  Virtual  Machine)  -  an  open 
source  Ada  compiler  that  compiled  from 
Ada  to  Java  bytecode  —  was  used  as  a  start¬ 
ing  point  for  the  compiler.  We  modified 
JGNAT  to  emit  CIL  instead  of  Java  byte¬ 
code.  The  resulting  compiler  is  called 
MGNAT  (GNAT  for  Microsoft  .NET). 


Also,  we  rewrote  the  Ada  standard  library 
packages  to  call  .NET  routines  instead  of 
those  from  the  Java  platform.  JGNAT  is 
no  longer  maintained  by  Ada  Core 
Technologies,  so  it  does  not  contain  any 
Ada  2005  features.  To  support  Ada  2005, 
MGNAT  reuses  code  from  the  latest 
GNAT  compiler  (with  some  modifica¬ 
tions)  [6].  GNAT  is  an  open-source  Ada 
2005  compiler  distributed  under  the  Free 
Software  Foundation  General  Public 
License.  GNAT  runs  on  many  different 
platforms,  but  not  .NET. 

To  make  using  the  compiler  easier,  we 
have  modified  Ada  Graphical  Integrated 
Development  Environment  (AdaGIDE) 
[7],  a  freely  available  development  envi¬ 
ronment  for  Ada,  so  that  the  A#  compil¬ 
er,  MGNAT,  can  be  selected  simply  by 
pushing  the  target  button  and  then  select¬ 
ing  the  .NET  radio  button. 

Using  .NET  Classes  in  Ada 

Whenever  you  mix  programming  lan¬ 
guages,  it  is  necessary  to  have  a  language 
binding  that  enables  communication 
among  components  written  in  different 
languages.  These  bindings  may  be  either 
written  by  hand  or  automatically  generat¬ 
ed.  Win32Ada  [8]  is  an  example  of  a 
handwritten  binding  to  the  Microsoft 
Win32  Application  Program  Interface 
(API).  The  problem  with  manually  writing 
such  a  binding  is  that  it  is  incredibly 
tedious  and  quickly  becomes  stale.  As  the 
Microsoft  Win32  API  developed, 
Win32Ada  was  not  kept  up  to  date. 

A#  provides  the  MSIL2Ada  (Micro¬ 
soft  .NET  Common  Intermediate  Lan¬ 
guage  to  Ada)  tool,  which  automatically 
generates  bindings.  MSIL2Ada  is  written 
in  a  combination  of  Ada  and  C#  and  uses 
the  .NET  reflection  classes  to  enumerate 
all  of  the  classes,  methods,  and  attributes 
of  a  .NET  DLL,  then  generates  corre¬ 
sponding  Ada  specifications. 

Consider  the  following  C#  class: 
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namespace  crosstalk  { 

public  class  Class!  :Superclass, 
Mylnterface  { 

public  color  my_color; 
private  string  s; 
public  Class! (string  x)  {...} 
public  void  package()  {...} 
public  static  color  get_color()  {...} 
private  int  get_value()  {...} 

} 

} 

MSIL2Ada  parses  the  compiled  DLL  con¬ 
taining  this  class  and  generates  the  follow¬ 
ing  Ada  specification  (corresponding  to 
only  public  attributes  and  methods); 

with  crosstalk.Superclass; 
with  crosstalk.Mylnterface; 
with  crosstalk.color; 
limited  with  MSSyst.String; 
package  crosstalk.Class!  is 
typeTyp; 

type  Ref  is  access  all  Typ’Class; 
type  Typ  is  new  crosstalk.Superclass.Typ 
and  crosstalk.MyInterface.Typ 

with  record 

my_color :  crosstalk.color.Valuetype; 
pragma  lmport(MSIL,my_color, 
”my_color”); 

end  record; 

function  new_Class1  (This  :  Ref  :=  nuii; 

X :  access  MSSyst.String.Typ) 
return  Ref; 

function  get_color  returncrosstalk. 
color.  Valuetype; 

procedure  package_k(This  :  access  Typ); 
private 

pragma  Convention(MSIL,Typ); 
pragma  MSIL_Constructor(new_Class1 ); 
pragma  lmport(MSIL,get_color,”get_color”); 
pragma  lmport(MSIL,package_k, 
’’package”); 
end  crosstalk.ClassI ; 

pragma  lmport(MSIUcrosstalk.Class1  ,”.ver 
1 :0:21 61 :1 591 3”,“[crosstalk]crosstalk.Class1  ”); 

In  the  Ada  code  above,  the  compiler 
directive  pragma  Import  specifies  that  an 
item  is  being  imported  from  a  different 
programming  language.  Several  new  Ada 
2005  features  are  used  in  this  binding, 
making  it  easier  to  read  than  similar  bind¬ 
ings  written  in  Ada  95.  First,  Ada  2005 
adds  interfaces,  which  are  styled  after 
those  in  Java  and  C#.  In  the  definition  of 
Class  1,  the  and  shows  how  to  specify  that 
a  tagged  type  implements  an  interface. 
Oddly,  in  Ada  2005,  only  child  classes  are 
allowed  to  implement  interfaces.  This 
poses  no  problems  in  mapping  the  C# 
types  as  all  types  in  C#  are  derived  from 
System.Object  (which  does  not  implement 
any  interfaces). 


Second,  the  new  limited  with  clause  in 
combination  with  new  anonymous  access 
types  makes  it  easy  to  map  mutually 
dependent  C#  classes.  A  limited  with  clause 
is  added  for  each  dependent  class  (as  is 
seen  for  MSSyst.String). 

Reserved  words  in  C#  and  Ada  differ, 
and  C#  is  case-sensitive  while  Ada  is  not,  so 
the  pragma  Import  is  used  to  map  C#  names 
to  Ada  names.  Note  that  since  package  is  a 
keyword  in  Ada,  _k  is  added  to  its  Ada  iden¬ 
tifier.  The  namespace  System  from  C#  is 
renamed  to  MSSjst  for  similar  reasons. 

A#  was  the  first  Ada  compiler  to 
introduce  the  object.method  syntax, 
which  has  now  become  part  of  the  Ada 
2005  standard.  This  means  that  program¬ 
mers  using  both  C#  and  A#  can  use  the 
same  object-oriented  syntax  for  method 
calls  in  both  languages.  In  Ada  95,  a  call  to 
the  package_k  method  would  have 
appeared  as: 

crosstalk.Class1.package_k(This=> 
Class1_  Ptr); 

In  A#  and  Ada  2005,  this  can  now  be 
written  as: 

Class1_Ptr.package_k; 

This  is  not  only  shorter,  but  simpler,  as 
the  programmer  does  not  need  to  worry 
about  what  package  a  class  was  declared  in 
to  call  a  method  on  it.  This  is  particularly 
helpful  for  non-dispatching  methods  (those 
declared  with  ‘Class),  as  they  may  be  in 
packages  where  superclasses  were  declared. 

On  the  Java  Virtual  Machine,  there 
were  only  base  types  (such  as  integer  and 
float)  and  class  references.  The  Microsoft 
•NET  platform  allows  for  the  creation  of 
types  that  stored  on  the  stack  are  passed 
by  value  (hence  the  name  Valuetype) 
instead  of  by  heap  reference.  To  resolve 
this,  we  have  added  the  reserved  word 
Valuetype.  The  get_color  method  returns 
something  of  type  crosstalk.color.Value-type. 
If  a  type  is  so  named,  then  the  compiler 
will  generate  code  for  it  according  to  the 
•NET  calling  conventions  for  Valuetype s. 
Since  there  are  no  pointers  for  these  types, 
a  full  with  is  needed  for  the  crosstalk.color 
package  instead  of  the  limited  with  used 
for  other  dependencies. 

The  C#  enum  is  another  example  of  a 
Valuetype.  Although,  as  previously  men¬ 
tioned,  it  differs  from  an  Ada  enumeration 
type.  A#  currently  maps  it  to  an  Ada  enu¬ 
meration.  However,  since  C#  enum  types 
do  not  support  determining  a  successor  or 
predecessor,  these  mapped  types  cannot 
use  Ada  enumeration  attributes  (such  as 
‘Pos  or  ‘Succ).  Unlike  Ada  enumeration 


types,  .NET  enumerations  can  have  multi¬ 
ple  names  corresponding  to  the  same 
value.  In  these  cases,  a  named  constant  is 
declared  for  each  additional  name.  In  cer¬ 
tain  cases,  enum  values  can  be  combined 
to  create  values  that  have  no  name  (e.g.,  in 
the  FontStyle  enumeration.  Bold  and  Italic 
are  listed  -  they  can  be  added  together  to 
create  a  Bold  Italic  style,  although  this  is 
not  listed  in  the  enumeration).  When  the 
type  allows  this,  we  provide  a  function  (+) 
for  performing  such  combinations.  The 
C#  enum  differs  so  significantly  from  an 
Ada  enumeration  that  it  would  be  more 
accurately  mapped  to  a  named  integer 
type  (e.g.  type  FontStyle  is  new  Integer).  This 
more  precise  mapping  may  be  accom¬ 
plished  in  a  later  version. 

Another  key  difference  between  C# 
and  Ada  data  types  is  the  use  of  strings.  In 
C#,  strings  are  stored  in  16-bit  Unicode, 
while  the  Ada  basic  string  is  eight-bit 
International  Standardization  for  Organ¬ 
ization  (ISO)  Latin- 1.  Since  it  is  expected 
that  strings  will  be  commonly  passed 
between  the  languages.  A#  provides  a 
unary  (+)  operator  to  perform  the  follow¬ 
ing  conversion. 

Csharp_String  :  MSSyst.String.Ref  :=  + 
’’hello  world”; 

When  calling  a  C#  method  that  takes  a 
string  as  a  parameter,  the  compiler  will 
automatically  insert  the  conversion: 

C1  :  crosstalk.Class1.Ref  :=new_Class1 
(X  =>  “hello  world”); 

Extending  a  .NET  class  in  Ada 

A  peculiarity  that  is  exposed  by  the  map¬ 
ping  to  Ada  is  the  appearance  of  the  this 
parameter  in  the  constructor  for  Class  1.  All 
C#  constructors  are  required,  as  their  first 
act,  to  call  a  parent  constructor.  Generally, 
the  no-argument  constructor  of  the  parent 
is  used;  however,  this  can  be  changed  in  C# 
by  using  base,  as  the  following: 

public  Classi  (string  x) :  base(x) 

This  indicates  that  parameter  x  should  be 
passed  to  the  superclass  constructor  that 
takes  a  string  as  a  parameter.  When 
extending  a  .NET  class  in  Ada,  the  call  to 
the  constructor  method  is  done  explicitly 
in  the  variable  declaration: 

function  New_Menultem(This  :  Ref  :=  null) 
return  Ref  is 
Super :  Menu  Item.  Ref  := 

Menu  Item .  New_Menu  Item 

(Menu  Item.  Ref(This)); 

begin 
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return  This; 
end  New_Menultenn; 

This  code  seems  a  bit  peculiar,  as  Super 
appears  to  be  an  unused  local  variable,  and 
the  function  looks  like  it  will  return  null; 
however,  the  compiler  generates  the  cor¬ 
rect  code  that  allocates  a  new  object  and 
calls  the  parent  constructor.  The  Ada  child 
class  also  needs  to  be  marked  with  the 
convention  MSIL  (Microsoft  .NET  CIL) 
and  have  its  constructor  marked  as  an 
MSIL  constructor  (as  shown  in  the  pack¬ 
age  crosstalk.ClassI) . 

Calling  A#  Code  From  C# 

Although  a  free  graphical  user  interface 
(GUI)  builder  tool.  Rapid  [9],  can  be  used 
to  develop  user  interfaces  for  the  .NET 
framework  in  Ada,  Visual  Studio  [1 0]  pro¬ 
vides  a  much  more  extensive  GUI  builder. 
Consequently,  it  can  be  advantageous  to 
use  Visual  Studio  to  develop  the  user 
interface  and  then  write  the  rest  of  the 
code  in  Ada. 

In  this  case,  you  create  a  DLL  from  the 
Ada  code  instead  of  an  executable.  A# 
comes  with  mgnatmake,  a  tool  which 
automatically  detects  dependencies  be¬ 
tween  Ada  source  files,  performs  the  re¬ 
quired  compilations,  and  combines  the 
results.  By  default,  mgnatmake  generates 
executables,  but  it  can  be  instructed  to 
generate  DLLs  instead: 

mgnatmake  msil2ada  -o  msil2ada_output. 
dll-  z  -largs  /DLL 

These  arguments  tell  mgnatmake  to  com¬ 
bine  all  of  the  dependencies  of  the  project 
MSIL2Ada  into  an  output  file  named 
msil2ada_output.dll  (-o),  with  no  main 
program  (-2)  and  to  create  it  as  a  DLL 
instead  of  an  executable  (-largs /DLL). 


In  Visual  Studio,  you  can  simply  add  a 
reference  to  this  DLL,  and  the  InteUisense 
will  automatically  suggest  the  Ada  meth¬ 
ods  (Visual  Studio  automatically  creates 
the  appropriate  language  binding). 
Because  .NET  does  not  allow  a  name- 
space  and  a  class  to  have  the  same  name, 
it  was  necessary  to  add  _J)kg  to  the  end  of 
the  final  Ada  package  name,  so 
P1  .P2.P3.Pul  would  be  referenced  as 
p1p2p3 _p)kgput.  Also,  it  is  necessary  to 
call  the  initialization  routine  generated  by 
the  binder  explicitly  from  the  C#  code  as: 

ada_msil2ada_outputj3kg.adainit(); 

The  binder  output  has  an  additional  ada_ 
prefix  on  the  package  name  (which  has 
been  given  the  _p)kg  suffix  as  previously 
described). 

Uses  of  A#,  Embedded  and 
Mobile  Devices,  and  More 
Interoperability 

The  most  widely  used  program  imple¬ 
mented  using  A#  is  RAPTOR  [1 1]  (Rapid 
Algorithmic  Prototyping  Tool  for 
Ordered  Reasoning).  RAPTOR  is  an 
open-source  visual  programming  environ¬ 
ment  designed  for  use  in  an  introductory 
computer  science  class.  RAPTOR’s  visual 
programming  model  is  based  on  flow¬ 
charting.  RAPTOR  is  being  used  in  an 
increasing  number  of  universities  across 
the  United  States  and  Canada  with 
inquiries  from  as  far  away  as  Japan. 

RAPTOR  is  an  interesting  use  of  the 
A#  technology,  as  it  incorporates  C#  and 
A#  code,  as  well  as  a  legacy  C++  graphics 
library.  Figure  1  shows  the  interrelation 
between  the  various  software  components 
in  RAPTOR. 

The  C#,  C++,  and  Ada  code  are  writ¬ 


ten  by  hand;  the  interoperability  DLL  is 
generated  automatically  by  Visual  Studio 
when  a  reference  to  the  COM  object  is 
added  to  the  project. 

A#  is  also  being  used  on  some  defense 
projects,  in  particular  to  port  Ada  applica¬ 
tions  to  embedded  and  mobile  devices 
using  the  .NET  Compact  Framework.  It  is 
a  trivial  matter  to  target  an  embedded  or 
mobile  device  using  A#.  Simply  adding 
xh^-compact  flag  to  both  MSIL2Ada  and 
MGNAT  instructs  these  tools  to  generate 
code  suitable  for  use  with  the  .NET 
Compact  Framework.  Two  of  the  plat¬ 
forms  available  with  the  compact  frame¬ 
work  are  the  Pocket  PC  and  the 
Smartphone  2003. 

A  final,  recently  added  piece  of  inter¬ 
operability  is  the  ability  to  interface  with 
legacy  Win32  DLLs.  In  C#,  you  would 
add  the  following  code  to  import  from  a 
Win32  DLL: 

[Dlllmport(“adagraph2001.dH”)] 
public  static  extern  int 

CreateGraphWindow(int  size); 

In  A#,  you  instead  do  the  following: 

function  Open_Graph_Window(Size :  in 
Integer) 
return  Integer; 

pragma  Export(Stdcall,Open_Graph_Window, 
“[adagraph2001  .dll]CreateGraph 
Window”); 

This  also  provides  a  function  body  (which 
will  be  ignored).  While  it  is  irregular  to  use 
a  pragma  Export  to  import  from  another 
file,  this  is  done  because  it  is  necessary  to 
generate  code  in  addition  to  merely  a  call, 
and  it  was  simpler  to  generate  a  body  on  a 
function  marked  for  export. 

Conclusions  and  Future  Work 

A#  has  demonstrated  the  viability  and 
usefulness  of  combining  Ada  with  other 
.NET  languages,  as  well  as  providing 
interfacing  to  legacy  Win32  and  COM 
libraries.  This  allows  developers  to  gain 
the  advantages  of  Ada’s  strong  typing 
while  also  leveraging  the  vast  number  of 
libraries  available  with  .NET  and  the  GUI 
builder  from  Visual  Studio.  Furthermore, 
A#  provides  an  easy  mechanism  for  get¬ 
ting  Ada  code  running  on  embedded  and 
mobile  devices  via  the  .NET  compact 
framework  (e.g.  Windows  CE,  Pocket  PC, 
Smartphone  2003). 

There  are  significant  areas  for  future 
work.  First,  we  are  currently  working  to 
fully  integrate  Ada  into  Visual  Studio  2005. 
Visual  Studio  2005  now  allows  extensions 
to  be  written  in  .NET  languages  (Visual 
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Studio  2003  required  the  extension  to  be 
written  using  C++  COM  objects),  so  the 
integration  code  is  also  being  written  in  a 
combination  of  A#  and  C#. 

Second,  version  2  of  the  .NET  frame¬ 
work  adds  generics.  Using  the  generics 
built  into  the  framework  to  implement 
Ada  generics  might  reduce  code  size  and 
make  the  genericity  of  Ada  constructs  vis¬ 
ible  to  other  .NET  languages.  This  will  be 
a  non-trivial  effort  as  the  generic  model  in 
•NET  is  not  as  fully  featured  as  that  in  Ada 
(it  allows  only  types  as  generic  parame¬ 
ters).  Also,  MSIL2Ada  and  MGNAT  need 
to  be  updated  to  allow  Ada  programmers 
to  use  generic  classes  written  in  C#. 

Finally,  while  A#  has  been  maintained  as 
an  academic  project  (even  though  it  is  in  use 
by  defense  contractors),  it  would  be  prefer¬ 
able  to  perform  technology  transfer  to  the 
private  sector,  which  has  greater  resources 
to  develop  and  maintain  this  product.^ 
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for  more  information  on  the  A#  pro¬ 
ject.  Developers  can  download  A#  for 
free. 
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Letter  to  the  Editor 


Dear  CrossTalk  Editor, 

Kevin  Stamey’s  sponsor  note,  “Why  Do  Projects  Fail?”  in 
Crosstalk’s  June  2006  issue  was  encouraging.  Software  peo¬ 
ple  are  finally  starting  to  realize  that  systems  engineering  is  nec¬ 
essary  to  their  success.  What  Stamey  observes  is  mostly  correct. 
But  he  does  omit  several  items,  some  of  which  were  touched  on 
by  the  articles  in  the  June  issue. 

He  omits  Configuration  Management  (CM).  Without  it  you 
are  doomed  to  fail.  Who  hasn’t  been  burned  by  some  cowboy 
coder  who  decided  to  make  an  improvement  without  telling  any¬ 
one,  let  alone  obtaining  authorization,  delaying  testing  and  caus¬ 
ing  previously  working  code  modules  to  fail  unexpectedly.  Even 
finding  the  latest  version  of  a  document  challenges  most  orga¬ 
nizations. 

But  CM  is  really  a  subset  of  communication  and  coordina¬ 
tion.  When  I  worked  in  acquisition,  I  included  a  glossary  of 
every  term  used  so  there  would  be  no  mix-ups,  as  in  Alan  Jost’s 
article.  Anyone  who  does  not  define  their  terminology  is  ask¬ 
ing  for  protests,  screw-ups,  and  lawsuits.  Why  including  a  glos¬ 
sary  isn’t  standard  practice  is  a  mystery.  It  should  continue  into 
the  development  work  by  instantiating  a  project  glossary  that 
goes  to  the  level  of  detail  of  the  units  used  in  calculations. 

As  Capers  Jones  alludes  to  in  his  article,  lack  of  adequate 
resources  is  a  root  cause  of  failure.  Lack  of  ethics  and  moral 


courage  on  the  part  of  management  and  engineering  exacer¬ 
bates  the  problem,  as  does  outside  influences  such  as  political 
pressure  and  executives  who  want  to  make  the  numbers  to  get 
their  bonus;  congress  may  cancel  funding  if  progress  is  not 
shown.  With  such  a  situation,  misleading  status  reports  are  sure 
to  result,  making  the  situation  even  more  critical  later  on. 

Tim  Perkins  has  the  best  high-level  diagram  that  I  have  seen. 
I  infer  that  it  puts  too  much  faith  in  CMMI-type  answers,  but  it 
captures  the  paths  to  the  real  root  causes.  However,  Item  150  is 
a  constraint  that  must  be  considered  in  the  Systems 
Architecture;  it  is  not  a  valid  cause  of  project  failure. 

Between  large,  complex,  unprecedented  systems  and  small 
routine,  incremental  improvements  to  COTS,  there  is  a  wide 
range  of  processes  that  should  be  used.  Processes  must  be  tai¬ 
lored  to  fit  the  situation.  This  requires  that  competent  people 
be  used.  Ones  who  understand,  not  merely  check  off  boxes  on 
some  list.  They  must  truly  understand  the  essence  of  what  they 
are  doing  and  not  just  chant  the  black  magic  incantations  they 
were  promulgated  by  some  professor. 

William  Adams,  PE,  Ph.D. 
<williamadams@ieee.org> 
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